1. Technical Field
The present teaching relates to methods, systems, and programming for telecommunications equipment testing or the like, for example, via network connections.
2. Discussion of Technical Background
With the advancement of telecommunications, the use of handheld devices has becoming increasingly ubiquitous. The industry has gradually shifted from massive production of desktop computers or laptop computers to massive production of a variety of handheld devices such as cellular phones, BlackBerry®, Personal Data Assistance (PDA), iPhone, etc. Traditionally, testing such devices after production is a laborious process and, hence, costly. In addition, due to the rapid development of various applications that handheld devices can support, it is common that new services or applications can be offered to users of existing devices. For example, in order to get such services, a user can take the device to a nearby shop to subscribe for the new service and to test whether new applications will run on an existing device properly. In this case, the personnel at the shop may assist the user to subscribe to the new service and test the device.
Traditionally, as a part of the process of testing applications on a handheld device, it is often necessary for a human tester to view information associated with a device being tested. Such information frequently relates to the features the device has, e.g., whether it has Visual VoiceMail (VVM), the billing system in which a Mobile Directory Number (MDN, i.e., the device's phone number) account information exists, the Mobile Equipment Identifier (MEID, i.e., the device's serial number) to which the MDN was assigned, the Account Number of the MDN, the effective date of the Mobile Telephone Number (MTN), the environments in which the MDN exists (e.g., Production and/or any of various Test environments), etc. To simulate a testing condition, it is also often necessary to make certain changes to some recorded features of a device being tested. For instance, to test whether a handset will properly support remote subscribing for the VVM service via the self-service feature, the VVM feature may need to be removed from the Class of Service (CoS) of an account to simulate a scenario in which a user is subscribing to VVM for the first time.
Due to the fact that there is likely sensitive data in both production and test environments, at least some of the features need to be tested in a secure manner, so that a tester is not allowed to inadvertently make unauthorized changes or update account information of existing customers of a service provider. Examples of information that should not be accessed by personnel performing the testing include the account information such as the incoming/outgoing calls of the device, or the unique identification of the device such as the MDN or MTN of the device. To ensure the security, in a conventional testing environment, either during the production or after service testing, permission to view such secure information and/or to make changes to secure features is typically provided only to a few authorized individuals, often accompanied with well-defined read/write access to such individuals. Given such a configuration, the testing process traditionally involves the following steps:                1. A tester (or the user) manually contacts an authorized individual, requesting either information associated with a device identified using an MDN or a change on a specific feature of the device        2. The authorized individual manually performs the task and then manually sends the response to the request back to the tester        3. The tester continues the rest of the testing based on the response from the authorized individual        
The process is manual to ensure the security of the information passed to the tester. The manual aspect of the existing testing processes makes the process slow and inefficient. In addition, to ensure confidentiality of the information, it is usually the case that only a few individuals are given the authority to access such information, to filter it for security reasons and, hence, this makes the testing process not only slow and inefficient but also error prone, sometimes leading to substantial delay. Therefore, a simple, automated, and yet secure approach to streamlining a testing process is needed.